QuickTime for Java or QTJ is a software library that allows software written in the Java programming language to provide multimedia functionality, by making calls into the native QuickTime library. In practice, it allows Java applications on Mac OS, Mac OS X and Microsoft Windows to support the capture, editing, playback, and export of many different media formats and codecs.
QTJ has been deprecated by Apple[1].
Contents |
Owen W. Linzmayer, in Apple Confidential 2.0, traces QuickTime for Java's genesis back to Kaleida Labs, a spin-off company created by Apple Computer and IBM, noting that it and some Unicode text classes were the only Mac software salvaged from the four-year, $150 million disaster. [2] Ported to the Mac OS, it was developed under the code-name "Biscotti", and first released as a public beta in 1999. [3]. Later versions were installed by default with Mac OS and Mac OS X, and was an optional part of the QuickTime install for Windows. As of QuickTime 7, QTJ is part of the standard QuickTime install on Windows, and QuickTime itself is installed by default with iTunes.
In 2003, Apple issued a Java 1.4.1 implementation that broke any QTJ applications that tried to run under 1.4.1 on Mac OS X. The underlying problem was Apple's move from Carbon to Cocoa for their AWT implementation, and the removal of a Java-to-native library called "JDirect" that QTJ relied on. QTJ applications could still run under Java 1.3.1, but apps that did not specify the version of Java they required, or that needed 1.4 features, were rendered unusable.
Later that year, Apple released a new version of QTJ that dealt with the incompatibilities, by offering a compatible but scaled-down version of the GUI classes. This 6.1 version of QTJ also radically changed the API, so that instead of having developers create GUI components and associate Movies or other renderable objects with them, the developers now needed to start with the Movie and request a suitable component from a factory. The new version also neglected to provide a component to show a visual preview of the input from a capture device, such as a webcam or camcorder. [4]
QTJ lays an object-oriented API on top of the native C-based QuickTime library. It does this by associating common structs and the functions that work with them into classes. For example, the Movie struct is the basis of the class quicktime.std.movies.Movie, with functions like NewMovieFromFile and GetMovieTrackCount becoming the instance methods fromFile() and getTrackCount() respectively. The result is more like a genuine object-oriented API than other C-to-Java adaptations (such as JOGL, which dumps the OpenGL header files into classes with thousands of static methods). [5]
The Cocoa-based QTKit is a similar attempt to put an object-oriented layer atop the procedural QuickTime library, using Objective-C.
Apple's use of the top-level package name quicktime violates the Java Language's Specification convention that packages use a reverse-domain-name scheme, such as com.apple.quicktime. However, as Apple owns the "QuickTime" trademark, there is no realistic chance of a namespace collision, the prevention of which is the purpose of the package naming convention.
It is important to remember that QTJ is not a Java implementation of QuickTime, it is a Java wrapper around native QuickTime calls. For this reason, it can only run on systems that have the QuickTime libraries installed, namely the classic Mac OS (which is no longer supported), Mac OS X, and Windows.
QTJ offers access to most of the native QuickTime library, including
As a wrapper around QuickTime, QTJ also inherits support for a vast collection of media formats and codecs, including MPEG-1, MPEG-4, H.264, AAC, Sorenson Video, Flash, 3GPP, WAV, AIFF, and more. Since QuickTime itself can be extended, QTJ can pick up support for formats such as DivX and Ogg Vorbis through the use of third-party QuickTime components.
The following example shows an AWT file-selection dialog and then tries to import and play the selected media file.
import java.io.File; import java.awt.*; import quicktime.*; import quicktime.std.movies.Movie; import quicktime.app.view.QTFactory; import quicktime.io.*; public class TrivialQTJPlayer extends Frame { public static void main (String[] args) { try { QTSession.open(); Frame f = new TrivialQTJPlayer(); f.pack(); f.setVisible (true); } catch (Exception e) { e.printStackTrace(); } } public TrivialQTJPlayer() throws QTException { FileDialog fd = new FileDialog (this, "TrivialJMFPlayer", FileDialog.LOAD); fd.setVisible(true); File f = new File (fd.getDirectory(), fd.getFile()); OpenMovieFile omf = OpenMovieFile.asRead (new QTFile (f)); Movie m = Movie.fromFile (omf); Component c = QTFactory.makeQTComponent(m).asComponent(); add (c); m.start(); } }
Most of the code in this example involves itself with setting up the GUI. The only calls to QTJ are the calls to OpenMovieFile.asRead() and Movie.fromFile(), which create a QuickTime movie from the specified file, and the calls to create an AWT component from the QTFactory. This example puts the movie into the frame and immediately starts playing it; if a control bar (aka a "scrubber") were desired, you would create a MovieController from the Movie and then create a component from the controller, rather than from the movie.
QTJ's acceptance is limited by its nature as a wrapper around Apple's proprietary QuickTime library. It does not exist for any platform other than Mac and Windows, and cannot until and unless Apple ports QuickTime to another platform, such as Linux.
Currently most of QTJ is broken on recent windows-running computers. Windows machines that use the no-execute (NX) page-protection security feature of recent CPUs cannot run even the demos without changing the configuration. This can be easily verified by a developer via a test-run of one of the demos coming with QTJ. An "execution protection violation" is reported and the program is aborted by Windows. This renders QTJ unsuitable for end-user application development due to the necessary complicated configuration of the NX feature.
Following the 2003 release of QTJ 6.1, Apple has made few updates to QTJ, mostly fixing bugs. Notably, QuickTime 7 was the first version of QuickTime not to be accompanied or followed by a QTJ release that wrapped the new native API's. QuickTime 7's new API's, such as those for working with metadata and with frame-reordering codecs, are not available to QTJ programmers. Apple has also not offered new classes to provide the capture preview functionality that was present in versions of QTJ prior to 6.1. Indeed, QTJ is dependent on some native API's that Apple no longer recommends, most notably QuickDraw.